Software supporting a plurality of languages is called “internationalized software”. In the internationalized software, a text string part to be displayed on a screen is separated from the source code, and the text string part thus separated is stored as an externalized resource file. The externalized resource file is referred to upon execution of the internationalized software, and used by the internationalized software to make a screen display. When such a configuration is employed, it is only necessary for a developer of the internationalized software to translate the externalized resource file to another language to make the internationalized software support the other language. Moreover, once the externalized resource file is translated, it is unnecessary to redo the translation even if the execution code is changed.
In a development process of such internationalized software, tests are conducted for various characteristics or aspects (hereinafter, referred to as “test categories”) to see whether the internationalized software operates properly in language environments of different countries. Among them, the tests concerning an output to the user include one that checks whether a message or other character string to be displayed to the user has been separated from the source code and externalized property as a resource file. In other words, this is a hard-coded character string detection test that confirms that the message or other character string to be displayed to the user is not directly described (i.e., hard-coded) in the source code. There also is a validation test of a sort result that checks whether a list of character strings is sorted properly in the order defined in each language, such as alphabetic order. Also conducted is a displayability test of language-specific characters that checks whether characters specific to each language are displayed properly without being garbled, for example.
Translation of the externalized resource file takes time. Thus, in the development process, it is not feasible to use a translated, externalized resource file for testing each problem category described above in each desired language. For this reason, there was conventionally developed a method for mock-translating an externalized resource file to use it as the externalized resource file that approximates certain attributes, such as character length, of a target language. In this conventional technology, the mock translation includes placeholder data, e.g., characters, that expands the spacing allocated to the text to accommodate for the spacing required for translations. In a preferred embodiment, all English text that would appear on the graphical user interface (i.e., buttons, menus, pop-up dialogs, dialog window titles, dialog text, error messages, help windows, etc.) is expanded using tildes, and is enclosed with brackets, i.e., [ ]. This mock translation data is stored in localization files and displayed in a software application in place of the English or foreign-language text. The GUI is then tested by visually inspecting each screen. The programmer or proofreader is able to easily recognize many errors that would occur if the GUI were to be displayed in a translated language, without requiring the ability to read any foreign languages. These errors, referred to as internationalization errors, include truncation, expansion, alignment, or other formatting errors, and programming errors such as text that is hard-coded, text missing from localization files, localization files missing from the program build, and text composed of more than one translated message (see U.S. Pat. No. 6,507,812 and U.S. Pat. No. 6,453,462). There also is a technology in which narrow or single-width alphabetic characters of the original language are all replaced with wide or double-width alphabetic characters to create a mock translation (see U.S. Pat. No. 6,425,123). In these technologies, it is confirmed that on a screen display of the output of the internationalized software that performs processing by referring to the mock-translated resource file, the added characters or the double-width alphabetic characters are displayed properly for each of the character strings of the original language. If only a character string of the original language is displayed, it is a hard-coded character string. Further, if any of the added characters or the double-width alphabetic characters is replaced with another character, it is a garbled character.